Currently an increasing number of video streaming techniques make use of so-called segmentation. For example, HTTP adaptive streaming (HAS), Scalable Video Coding (SVC) and spatially segmented video (e.g. tiled video) use segmentation on the basis of time, quality and space respectively. During the segmentation process a so-called manifest file will be generated which describes the relation between the different segment files and/or streams and the location where the segments may be retrieved. A segment file may relate to a file comprising segment data, which may be retrieved by a file retrieval protocol, e.g. HTTP or FTP. Similarly, a segment stream may relate to a stream comprising segment data which may be retrieved by a streaming protocol, e.g. RTSP/RTP or HAS. A segment file or stream hereafter will be referred to as a segment. Further, video, or more in general, content rendered by a segmentation scheme may be referred to as segmented content.
Segmented content may be used to dynamically adjust to changing bandwidth requirements, e.g. by switching from a high to a low quality video stream. Moreover, segmented content may also allow for discrimination between popular and less popular video segments. For example, typically content associated with the beginning of a video will be watched (downloaded/accessed/retrieved) more often (more popular) than content at the end. Similarly, low-bitrate lower-quality video content (e.g. the lowest resolution HAS segments or the SVC base layer) will be watched (downloaded/accessed/retrieved) more frequently than high quality content (e.g. higher-resolution HAS segments or an SVC enhancement layer).
Hence, when segmenting content, certain segments will be (much) more often requested by consumers than other segments. This property may be advantageously used by a content delivery network (CDN), which is configured to deliver content to a consumer. It may for example store the segments associated with more popular content at multiple nodes in the CDN so that the bandwidth problem (as getting many popular segments from a too remote server may clog up network bandwidth) may be reduced and efficient delivery is guaranteed. A CDN content location manager may centrally manage the locations within the CDN where the segments may be retrieved.
In order to enable a client to access segments stored in a CDN, the client is provided with a so-called manifest file identifying a list of segment identifiers and segment locators pointing to locations in the network, which enable the client to retrieve the segments. Typically, a client is configured to retrieve segments such that the segment buffer associated with the client (device) is loaded with a predetermined number of segments before play-out is started. Furthermore, during play-out, the client continuously retrieves segments on the basis of the manifest file so that sufficient segments are kept in a buffer. This way, latencies associated with segment retrieval do not interfere with the seamless play-out of the segments.
In some cases however, a client may allow a user to interact with the play-out of the content (e.g. fast-forwarding, panning, zooming and/or tilting). Further, a user may instruct a client to switch to another rate or video quality. In all of the above cases, play-out of a segment may be required that is not available in the buffer, so that the client will start retrieving that segment on the fly (from the CDN or other network). This process however may take considerable time because the segment needs to be located and retrieved using a resolving process, which may involve DNS look-ups and HTTP redirects. Moreover, in some cases (content) segments associated with a content item (e.g. a video/movie) may be stored at (CDN/other network) nodes, which belong to two or more different CDNs. In that case, no central location manager is available to locate the segments in the different CDN domains. Therefore, a manifest file associated with a first CDN may only refer to a routing function in the further CDNs as the first CDN has no knowledge about the location of the segments in the second CDN. Every time a segment from another (second) CDN is requested, a routing request to that other (second) CDN is required. In addition, one or more further routing requests (and responses) may be generated in the other (second) CDN. Such requests may generate request-routing delays so that its takes a longer time, up to several seconds, for a client to receive the requested segment.
Hence, from the above it follows that without any user interaction, delays associated with DNS request, redirections and/or inter-CDN (CDN-I) request routing will have little impact on the user perception of the quality of the (video) stream, as the client will typically have a few segments buffered, allowing for some slack. If however user interaction with the (segmented) content is allowed, play-out of a segment that is not available in the buffer may take considerable time because the segment needs to be located using a resolving process. This process may take up to several seconds in case of complex or interconnected CDNs so that seamless play-out of segmented (video) content is no longer possible and the user experience is seriously downgraded.
Hence, there is a need in the art for efficient streaming of segmented content to a client. In particular, there is a need for methods and systems providing seamless play-out of segmented content even in case a user interacts with the segmented content.